home *** CD-ROM | disk | FTP | other *** search
- Path: news.nyu.edu!acf4!halvin
- From: halvin@acf4.nyu.edu (halvin)
- Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
- Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
- Date: 10 Apr 1996 15:24:28 GMT
- Organization: New York University
- Message-ID: <4kgjrc$4d@news.nyu.edu>
- References: <dewar.828846122@schonberg> <828903511snz@genesis.demon.co.uk>
- NNTP-Posting-Host: acf4.nyu.edu
- X-Newsreader: NN version 6.5.0 #5 (NOV)
-
- Lawrence Kirby <fred@genesis.demon.co.uk> writes:
-
- >>Consider for example, also answering your question about ANSI being
- >>a misleadng guide to portability, the return type of sprintf. I don't
- >>have SPEC1170 on hand, but it is a good guess that it is ANSI compliant
- >>here (return type int), but BSD heritage unices (like SunOS) return
- >>char *.
-
- >In any ANSI compiler/library sprintf returns int. Tell me of any modern
- >system which doesn't make the correct functionality available in a library,
- >if not the default. These days this is a non-issue with regards to
- >portability (even considering Sun systems).
-
- this might be slightly off-topic, but isn't there a difference between the
- ANSI and POSIX versions of fprintf? if i remember correctly, the ANSI version
- returns 0 on success and EOF on failure -- but the POSIX version returns the
- number of characters printed, or a negative number to indicate failure.
-
- so which behavior should one expect in an ANSI C application that happens
- to run in a POSIX-compliant environment? a student stumbled upon this issue,
- and i didn't really have an answer, as i had thought that POSIX was a proper
- superset of ANSI C.
-
-